Universal payment processing

ABSTRACT

A computerized universal payment method to allow merchants with differing risk tolerance, transaction fee tolerance, and payment time tolerance to optimize customer payment transactions that have different risks, transaction fees, and transaction times. Here customer payments are converted to a synthetic financial account (a universal payment account) that acts somewhat like a financial marketplace between a plurality of merchants and customers. The method adjusts for the risks, transaction fee, and payment times associated with a customer&#39;s particular mode of payment, as well as adjusting for the merchant&#39;s tolerance for risks, transaction fees, and payment times, as well as optionally the merchant&#39;s knowledge about the customer. Thus, given permission, a customer paying by a high commission credit card, may upon merchant election have this payment converted to a low commission electronic check, and vice versa. Various electronic transaction headers, point-of-service, electronic market, and customer permission factors are also discussed.

CROSS REFERENCE TO RELATED APPLICATIONS

This invention is a continuation of application Ser. No. 13/225,437,“UNIVERSAL PAYMENT PROCESSING”, inventors Arnold N Birenbaum (nowdeceased) and Michael Milan Radlovic, filed Sep. 3, 2011; the contentsof which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention is in the general field of electronic payment methods,and more specifically as related to point-of-sale transactions betweencustomers, merchants, and merchant banks

2. Description of the Related Art

Electronic payment methods, in which consumers can conveniently pay bycredit cards, debit cards, electronic checks, and other payment methods,have become popular in recent years. Generally, these methods areimplemented by various computerized devices, including variouspoint-of-sale terminals, communication networks (e.g. everything fromanalog telephone lines to high speed dedicated computer networks,including the Internet), computer servers, databases, and the like.

Electronic payment methods facilitate commerce because customers canmore easily make quick decisions to purchase items and services withoutthe burden of having to carry cash, or having to pay using slow andlaborious methods such as mailing cash or checks. Merchants alsoappreciate these various electronic payment methods because theystimulate business. In particular the practice of extending at leastshort-term credit card credit to customers stimulates commerce becausecustomers to not have to save up for long periods of time beforepurchasing items and services, and thus are more open to newexpenditures.

Unfortunately, some customers do not always pay their bills on time, andsome customers do not pay at all. Thus, as for any type of non-cashpayment there is always some element of risk involved in electronicpayment methods.

Many merchants dislike this risk, and as a result, various electronicpayment intermediary services, most famously Visa and MasterCard, haveemerged to help merchants manage risk. Credit card services such as Visaand MasterCard agree that provided that the merchant complies with theirrules, Visa and MasterCard will assume at least some of the risk ofcustomer non-payment.

These services charge both participating merchants and customers forthis risk management function. Customers are charged varying interestrates on the balances in their credit accounts according to variousformulas, such as FICO scores. Merchants are also charged as well,typically on the order of a 3% transaction fee per transaction.

By contrast, other forms of electronic payment are often lower risk.Debit or ATM cards, for example, which draw upon consumer money that ispresumed to be already on deposit in a bank or other financialinstitution, are considered to be less risky. Thus, in contrast to the3% rates charged to merchants for credit card purchase, electronic debitcards may charge the merchant only about 60 cents per transaction.

However there is still some element of risk even with debt cards,because due to the high speed of the electronic transactions, there isalways a chance that the debit card limit information may be out ofdate, if only by a few minutes or seconds, and thus there is someremaining chance of payment problems.

By contrast, electronic checks, which often take several days to clear,give the lowest level of risk. Due to the high efficiency of moderncomputerized communication and database methods, absent risk, the actualtransaction costs are quite low, and thus the merchant may only becharged a few cents (e.g. around five cents) per transaction, and theconsumer will often be charged nothing.

BRIEF SUMMARY OF THE INVENTION

The invention is based, in part, on the insight that the presentelectronic payment system, although forming the basis for most of themodern economy, is in some respects inefficient, particularly from thestandpoint of the merchant, and that an alternative method of electronicpayment would be desirable.

For example, depending on customer choice of payment method, themerchant return from the same customer of the same $100 item from amerchant may range from as much as $100 (cash on the spot) to $99.95(electronic check) to $99.40 (debit card) to $97.00 (credit card). Thevarious payment times can range from instant payment (cash or creditcard) to up to several days (electronic check). Many merchants operateon thin margins, and in aggregate, these differences over manytransactions can have a huge impact on merchant profitability.

Unfortunately merchants are somewhat limited in their ability to suggestmore efficient methods of payment to their customers. The message,“please don't pay by credit card because we don't really trust you, andwe also really need the money” just does not go over well. Thealternative message, “please pay by check because we are really cheapand need all the money we can get” lacks charm as well, and the message“we're about ready to go under, so please pay by cash or some other waythat we can get money today, we'll accept the higher payment fees” isperhaps less than optimal as well. Thus in general, merchants are oftencompelled, at least by business and social considerations, to providevarious methods of payment, to charge the same price for their items andservices, regardless of customer method of payment, and to grit theirteeth and smile at whatever the customer chooses.

The invention is also based, in part, on the insight that the presentmethods of managing consumer risk do not adequately take differencesbetween merchants into account. In particular, the present invention isbased upon the insight that an improved electronic payment method thattook into account differences in between individual merchant's tolerancefor risk, need for rapid payment, and need for low payment fees mightoffer some compelling advantages for electronic commerce. In someembodiments, the system might also utilize the merchant's knowledgeabout the customer making the transaction to achieve higher efficiencyas well.

The invention is also based, in part on the insight that such animproved method should ideally allow merchant's to reset a method ofcustomer payment, at least with customer approval, to an alternativemethod of payment that best meets the merchant's particular tolerancefor risk, need for rapid payment, need for fast payment, and optionallyalso knowledge about the customer.

According to the invention, in at least one embodiment, merchantsaccepting payment by one modality may form an electronic marketplacewith other merchants accepting payment by a different modality, and withappropriate exchanges of information (e.g. user identities) to satisfyvarious anti-money laundering statutes, as well as other statutes suchas the patriot act, form an electronic payment exchange.

In alternative embodiments, if for example a customer pays by creditcard, but the merchant is confident in the customer, and/or hassufficient financial resources so that the merchant is willing toself-insure against customer risk, or is willing to put up with a longerpayment cycle, then the invention might also allow the merchant toautomatically redirect this payment to an alternative payment method,such as debit card or check. Conversely a merchant who has a cash flowissue, and who wants to accelerate an echeck payment, might elect to paythe higher charges to speed up the transaction, with or withoutassumption of risk according to merchant preference.

The invention is also based, in part, upon the insight that in order tofacilitate such an improved method, what is needed is a new type ofuniversal payment account, computerized method, and system withassociated account information, permissions, privileges, exchangealgorithms, and payment exchange methods that allows merchants to makethese conversions as desired.

Thus in some embodiments, the invention may be a computerized universalpayment method to allow merchants with differing risk tolerance,transaction fee tolerance, and payment time tolerance to optimizecustomer payment transactions that have different risks, transactionfees, and transaction times. In some embodiments, the method may operateby converting customer payments are to a synthetic financial account (auniversal payment account) that acts somewhat like a financialmarketplace between a plurality of merchants and customers. The methodadjusts for the risks, transaction fee, and payment times associatedwith a customer's particular mode of payment, as well as adjusting forthe merchant's tolerance for risks, transaction fees, and payment times,and optionally the merchant's knowledge about the customer. Thus, withproper permissions, a customer paying by, for example, a high commissioncredit card, may upon merchant election have this payment converted to alow commission electronic check. Alternatively a customer paying byelectronic check might have this payment converted to a credit cardpayment if the merchant has a rapid need of funds, or optionally doesnot fully trust the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows the prior art method of payments, where each customerpayment is directed to the merchant without any change in payment form.

FIG. 1B shows the universal payment invention where an electronic markethelps match the characteristics of a particular customer's payments (interms of risk, payment costs, and payment times) with the individualneeds of each merchant, and where a payment initially made in one formcan be converted to a payment made by a different form.

FIG. 2 gives an overview of how the universal payment method can helpallow merchants, with varying tolerance for payment risks, paymentspeed, and payment transaction costs can use the universal paymentsystem to handle different customers with different means of payment,each payment having different risks and payment speeds.

FIG. 3 shows an example of the universal payment method can be used totake a point-of-sale transaction (in this example a credit or debit cardswipe), and if missing permissions or eligibility is absent, eitherprocess the transaction by prior art methods, or alternatively handlethe transaction according to the invention's universal payment methods.

FIG. 4 shows a further example of how the invention's universal paymentmethod can act to first convert the payment data to the universalpayment account, and then in turn transfer the payment information fromthe universal payment account to the merchant account.

FIG. 5 shows how a merchant bank can use the universal payment method tohandle transactions from different point-of-sale methods and differentpayment sources, and provide the merchant end user with a comprehensivepayment system optimized for that particular merchant's needs.

FIG. 6 shows how an aggregator, often used by larger corporations, cantake transactions from multiple point of sale devices, multiple paymentsources, and multiple merchant banks, and ultimately supply a largermerchant with a comprehensive payment system optimized for thatparticular merchant's needs.

DETAILED DESCRIPTION

It has been decades since the original electronic financial transactionstandards and data formats were created for the payment card and checkprocessing industries. Since this time, many new electronic paymentstandards, such as Internet specific formats (SET) and gateways,standards for digital check images, and the like have added newelectronic data formats that are specific to their respective functions.

Some of the various financial transaction standards and regulationspresently in effect for financial transactions include the Associationfor Retail Technology Standard (ARTS) standards, unified Point of Sale(POS) standards (e.g. UnifiedPOS). In addition to these standards, thereare many laws and regulations as well, including various Federalregulations such as the various Federal Reserve System regulations (e.g.12 CFR 201-233, 12 CFR 250, 12 CFR 208 and 225) the Patriot Act, variousanti-money laundering statutes, and so on.

Over the last few decades, there have also been major advances in thecomputer system hardware, software, and networking capability used toconduct these electronic financial transactions. The trend now, incontrast to the more isolated data world of just a few years ago, is tomove to a world where data is more freely shared; allowing formerlyseparate functions to now become more highly integrated and automated.

Many of these financial transaction standards and data format wereoriginally optimized in an environment where communication networks wereexpensive. By contrast in today's world, advances in electronic networksare such that communications are now the smallest part of the financialtransaction cost structure. Instead, the financial cost structures nowlargely revolve around risk management. This risk management is also afunction of available data, in particular data regarding the customer.

As previously discussed, at present, merchants are required by variouslegacy electronic transaction systems to process their various paymenttransactions in the same manner in which the payment transaction wasoriginally presented. As a result, merchants often end up in situationswhere they are paying higher transaction costs than the merchant wouldlike (i.e. paying credit card risk management fees when the merchant iseither able to self-insure, or alternatively where the merchant knowsthat the customer is trustworthy), or where the merchant is waitinglonger for payment than optimal (i.e. customer has paid by check, butthe merchant is low on cash and would have been willing to pay extra forfaster access to cash).

By contrast, the present invention utilizes a new payment processingsystem and method, here called a universal payment system, universalprocessing method, or occasionally in the alternative universal paymentaccount or universal payment marketplace intended to help minimize theseproblems.

As previously discussed, in one embodiment, the invention may be acomputerized universal payment method to allow merchants with differingrisk tolerance, transaction fee tolerance, and payment time tolerance tooptimize customer payment transactions that have different associatedrisks, associated transaction fees, and associated transaction times.The method will generally involve first converting an initial customerpayment, which may have been made using a method that at least initiallyspecified a first customer payment method, risk, transaction fee, andpayment time, into a universal payment account.

To show the method and system of the present invention, first considerprior art payment methods, as shown in FIG. 1A. Here a first customer(100) may have paid a first merchant (102) by a slow but low paymentcost method, such as electronic check. Although this particular merchant(102) may have a severe cash flow problem, and really would prefer aquicker payment, the merchant has no choice but to accept a slowelectronic check. Similarly a second customer (104) may have paid asecond merchant (106) by credit card. This second merchant may know thatthe first customer is trustworthy, and may have no immediate need forfunds, and thus would find it more ideal to be paid by electronic check.However this merchant also is stuck with the method of payment aspresented by the customer.

The universal payment system, method, or account may be implemented in avariety of ways.

In one embodiment, the various conversion factors required to transferfunds from the initial customer payment to the universal paymentaccount, and then back to the various payment modalities requested bythe merchant, may be computed based on various factors, such as a firstdiscount factor that takes into account the risk, assuming the originalcustomer method of payment, that the customer may default on thepayment, a second discount factor such as the commissions associatedwith the original customer method of payment, and a third discountfactor that may be based on the time value of money—i.e. the speed ofpayment associated with the original customer method of payment.

As an example, assume here that the ideal universal payment account(that is form that has the lowest discount from cash) would a zerotransaction electronic check (that is money drawn from an account knownto have sufficient funds) that would clear instantly. In thishypothetical ideal, a first $100 customer payment to a first merchantwould translate into the same $100 in the universal payment account.

However in real life, if the first customer's electronic check costs$0.05 in transaction costs, then the $100 customer payment, if it wouldclear instantly translates into only $99.95 in the universal paymentaccount for the first customer.

In fact, assuming that the typical electronic check would take 3 days toclear, then the value of the first customer's payment in the universalpayment account would be further discounted by the 3-day time value ofmoney.

By contrast, consider the ideal universal payment amount for a secondcustomer that has just paid a $100 fee by to a second merchant by creditcard. Assuming a nominal credit card fee of 3% would translate into$97.00 in the universal payment account, but here since credit cardsnormally clear almost instantly, the time value of money discount wouldbe almost zero.

In this example, the second merchant may know (e.g. from its owninternal records) that the second customer is trustworthy, and furtherthe second merchant may have sufficient funds so that the time value ofmoney for that particular second merchant for a three day period (i.e.the time for an electronic check to clear) is low. The second merchantwould much rather have the $100 or at least $99.95 without the creditcard commission, and the second merchant in this example would bewilling wait the three days for an equivalent type electronic check toclear.

Here, according to the invention, the second merchant would inform thecomputerized system that it would much rather take $99.95 in the form ofan electronic check.

In the above examples, the universal payment system was shown beingimplemented by relatively static exchange rates that were based ontypical transaction fees. However alternative mechanisms forimplementing the system are also possible, and in some cases perhapseven preferable.

Consider the question of the true 3-day time value of money from theperspective of various merchants. For some merchants, this value may beas little as the prime interest rate computed over three days. Howeverfor other merchants, such as merchants in distress, this true valuemight be much harder, perhaps more comparable to what the first merchantwould pay to sell its receivables in a factor financing type financialtransaction. This type of situation can be used to create an electronicexchange or marketplace where a merchant more in need of rapid cash canbid for access to rapid cash, and receive access to such rapid cash froma merchant or other financial institution with a lower need for rapidcash, and so on.

Thus in some embodiments of the invention, the time value of money usedto derive the various exchange rates or conversion factors for theuniversal payment account may be set by a competitive market among thevarious merchants or other financial entities participating in thesystem. Competitive bidding could also be used to encourageparticipating merchants to lend funds to the system as well.Alternatively this time value of money rate and other universal paymentrates may be set by system policy, financial regulatory agency, or othermechanism.

In this embodiment, the invention's universal payment system and methodmay be implemented by creating a new type of electronic transactionsystem that acts as an exchange between many customers, many differentcustomer payment methods, and many different merchants. This embodiment,in at least some respects, acts somewhat like a cross between a veryshort term financial money market, and a method of adjusting ornormalizing payment amounts in a manner that adjusts for payment risks,fees, and times versus merchant financial needs in a manner that isquite superior to prior art methods.

An example of the electronic exchange embodiment of the invention isshown in FIG. 1B.

Here the invention's universal payment method acts somewhat as amatchmaker or electronic marketplace, allowing an instant “mix andmatch” between various forms of payment, but again with proper tracingand auditing functions to be in compliance with all due financial lawsand regulations.

In this example, the first customer (110) has paid by a slow electroniccheck, but the first merchant (112) would really rather pay extra to getthe money quickly. By contrast the second customer has paid by creditcard (114), but the second merchant (116) who is not in a rush, truststhe customer and would really rather not pay the 3% commission.According to the invention, the universal payment account (118) actssomewhat like an electronic marketplace between the various customersand merchants, and allows (with proper electronic documentation andtracing to satisfy any anti-money laundering statutes, and otherstatutes such as the patriot act) participating merchants and customersto sort their various financial transaction in a way that promoteshigher transaction efficiency.

As a net result, in our example, the first customer's payment byelectronic check (110) would be diverted to the second merchant (116)who doesn't want to pay a high transaction fee, while the secondcustomer's payment by credit card (114) would be diverted to the firstmerchant (112) who really needs the money quickly, and who is willing topay a higher transaction fee to get it. Here this matching and diversionprocess will typically be done by a computer, or often a bank ofcomputer servers, which will often store the various types of conversionand transaction data need to perform this “mix and match” process.

Although the computer servers that implement this “mix and match”process, and/or create the marketplace or other mechanism needed toprovide the proper exchange rates to implement the universal paymentsystem, could in principle be located anywhere, due to the sensitivenature of the various financial transactions, it is anticipated thatregulators will likely require the system to be closely supervised andregulated. Thus at least this portion of the system may likely beperformed under the supervision of a bank or other regulated financialinstitution, and will frequently be described in this application asoccurring in a merchant bank, although of course other possibilities areboth contemplated and claimed.

The invention's method is intended to be implemented in the form ofvarious types of financial transaction software, running on varioustypes of computerized devices, including various point-of-salecomputerized devices, networks, computer servers, banks of servers (e.g.cloud computing), and mainframe servers

Thus in practice, the various conversion factors required to convert toand from the universal payment account may be done by various methods,including system policy, fixed exchange rates, or standard financialmarket rates. However in at least some embodiments of the invention,these conversion factors may be settled by competitive electronic marketbidding between the various merchants, and or other entities (e.g.banks, financial institutions, and the like) participating in theprogram. Again in these embodiments, the invention creates an electronicmoney market to that exists for approximately the duration of the floatperiod required for a long duration payment method, such as anelectronic check, to clear.

For purposes of this discussion going forward, assume that the variousmerchants and other financial entities have established the variousconversion factors needed to implement the universal payment method asper the current market conditions at the time of the transaction.

Prior art financial transactions are often accompanied with varioustypes of header information or data, such as information pertaining tothe identity of the customer (required in the US under the patriot act),identify of the original point of sale device, ultimate beneficiary ofthe transaction, and other types of information as well. Thisinformation accompanies the financial transaction as it makes its waythrough the system.

The invention's method operates, in part, by attaching additional data,in the form of a universal payment trait and optimization header, tothese various payment transactions, such as point-of-sale transactions.This additional data can either be added as an extension to prior artfinancial transaction headers, or alternatively can be added as its ownseparate header, as desired.

The additional payment header data required by the invention may includedata that defines what payment outcome the merchant wants (e.g. fastestclearing time, least expensive clearing time, or least risk). This datawill generally be accompanied by a record that has generic data—i.e. anormalized data model of all payment types) to produce any payment type.

This transaction will be initiated by the customer (either by a personaltrait card, mobile application, terminal entry, and so on) and then besent to a new type of bank processor.

The bank will also have automated records of the stored contracts withthe merchant's customers allowing the conversion of the paymentinstrument to another payment type (e.g., a loyalty card into anelectronic check). The bank processor will accept the header and paymentrecord and process the header by searching the available options todetermine the “best” payment option. It will then convert the genericrecord to the appropriate payment format and process through theappropriate payment system for authorization and/or clearing. A receiptfor the customer will be returned.

In some embodiments, a retailer using this invention and format couldrequest a fee for providing compliance/risk information. This can bedone by submitting an option to give credit for additional informationthat is provided.

In some embodiments, with the invention a credit card could be swipedand the merchant processor would use the universal payment system andmethods to change this payment to an electronic check. This may, ofcourse, require present or prior consumer approval, as well assettlement reconciliation between the different systems, and areconciliation of the rules between the different systems.

In some embodiments of the system, merchants who have informationpertaining to the risks involved with a particular customer can use thisrisk information to further enhance payment efficiency. Here this riskinformation may be derived, at least in part, from non-publicinformation, such as the merchant's record of customer purchases,payment history, and general loyalty to the merchant over time. Forexample, a customer who has routinely purchased from a merchant foryears without problems might be automatically assigned to a lower riskcategory, and so on.

FIG. 2 gives an alternate perspective of how the universal paymentmethod can help allow merchants, with varying tolerance for paymentrisks, payment speed, and payment transaction costs can use theuniversal payment system to handle different customers with differentmeans of payment, each payment having different risks and paymentspeeds. Here the perspective is from the standpoint of a singlemerchant, and the complexities of the system in terms of operating afinancial market place over a plurality of different merchants, aspreviously shown in FIG. 1B, are ignored in FIG. 2.

In FIG. 2, the merchant may be a larger merchant with multiple sites,and this merchant may be accepting payment from a plurality ofcustomers, using a plurality of different payment methods, and using aplurality of different point of sale terminals. Further in this example,assume also that the merchant is keeping track of its customers, and canidentify frequent, long term, or good customers (low risk customers)from new customers, that the merchant has not done business with before,and thus who may have unknown risk.

In this example, the merchant's point of sale terminals can be devicessuch as standalone, multi-lane store based, multi-lane corporate based,Personal Computer terminals (e.g. Via PC), terminals included in retailsystem, terminals included in the restaurant system, potable standaloneterminals, mobile phone terminals, offline terminals, internet (e.g.PayPal) terminals, mail order terminals, telephone order terminals, orother point of sale mechanism.

Thus in FIG. 2, customers 1-6 (200, 202, 204, 206, 208, and 210) may bepaying from different point-of sale terminals and/or using differentpayment methods. In (200), customer 1, that the merchant, perhapsbecause that customer has used the merchant for years, knows is low riskis paying by credit card, which is also low risk and delivers paymentrapidly, but which also has high fees. In (202) customer 2, that themerchant cannot identify as a previous customer, and who thus has anunknown risk, also is paying by credit card. In (204), customer 3, knownby the merchant to be low risk is paying by debit card, which is lowrisk but slow. In (206) customer 4, not known by the merchant, is alsopaying by debit card. In (208) customer 5, known by the merchant to below risk, is paying by check. In (210), customer 6, not known by themerchant, is also paying by check.

Under the invention, all forms of payment are sent, along withappropriate informational headers, from the various point-of-salecomputerized devices over a network to the computers, computer servers,and the like that host the universal payment system (212).

Depending on the universal payment system rules and policies (normallyimplemented by software on the computers, computer servers, and thelike, that host the universal payment system (212), the merchant will beable to factor the merchant's overall financial needs (214) (e.g. needfor fast payment, need for minimum service fees, need for minimum risk),as well as, in some embodiments, information about the risks associatedwith the customers (e.g. customer 1-6) who are making the varioustransactions.

In some embodiments of the invention, the merchant (216) will be able touse information (218) about the risk profile of each individual customerto direct the universal payment system to transfer payments from onemodality (e.g. credit card) to another modality (e.g. echeck) accordingto merchant direction for each individual customer. In this embodiment,for example, merchant (216) might direct the universal payment system(212) to change customer 1 (200) payment from credit card to e-check(224) because the merchant trusts the customer, and thus wants tominimize transaction costs. Similarly the merchant might direct theuniversal payment system (212) to change customer 6 (210) who is writinga check, but who is unknown to the merchant into a safer but moreexpensive payment method such as a credit card style etransfer method(220). The merchant might also elect to keep the payment from customer 3(204), known to the merchant, and known as being low risk, in itsoriginal payment format (222).

Allowing merchants to direct payments at the individual customer levelhas clear advantages at the individual merchant level, but potentialdisadvantages at the system level, because a merchant with greatcustomer knowledge could potentially “game the system”, to thedisadvantage of other merchants using the universal payment system. Thusin some embodiments, system policies may be set up to restrict thislevel of granularity, and for example may restrict or outright preventmerchants from using information about the risk properties of theindividual customers at the individual transaction level. Here thesepolicies are easily implemented in the form of various softwarepermissions at the universal payment system level, and these policiesmay be adjusted, based on use data, regulatory directives, or othermethod, to optimal settings.

The merchant's customers in principle can be using many different formsof payment. These various forms of payment can include Credit Cards,Checks, EBT, Drafts, Promise-to-pay, Script, Debit Card, Gift Card,Payroll Card, ACH, ATM Card, Paypal, Mobile phone, FOB or NFC device,coupons, discounts, cash, ePay or Bill pay, echeck, cross bordertransfers, wire transfer, Giro (payer instigated payment transfer fromone bank account to another bank account, e.g. Automated Clearing Housefor direct deposit payments), Money Order or other form of payment.

FIG. 3 shows an example of how the universal payment method can be usedto take a point-of-sale transaction (in this example a credit or debitcard swipe), and if permissions or eligibility are present or absent,either process the transaction by prior art methods, or alternativelyhandle the transaction according to the invention's universal paymentmethods.

FIG. 4 shows a further example of how the invention's universal paymentmethod can act to first convert the payment data to the universalpayment account, and then in turn transfer the payment information fromthe universal payment account to the merchant account.

FIG. 5 shows how a merchant bank can use the universal payment method tohandle transactions from different point-of-sale methods and differentpayment sources, and provide the merchant end user with a comprehensivepayment system optimized for that particular merchant's needs.

In some embodiments, the invention may include the following operations.Here assume that a merchant bank has modified its system to use theinvention's universal payment processing methods.

First, a customer signs up for universal payment process and primarypayment vehicle. They then send to the merchant's merchant bankprocessor. second, this customer uses a payment vehicle at a merchant'spoint of sale. Third, the merchant's point-of-sale computerized deviceor other equipment encrypts the sale data and universal payment formatdata (e.g. header data), and sends it to a merchant bank processor.Fourth, the merchant bank processor decrypts the universal paymentformat and, using the header, searches for the best payment method toemploy as per the merchant's specified preferred payment methods. Fifth,the merchant bank processor transforms the incoming universal paymentformat into the appropriate payment method, and sends the transaction tothe appropriate payment system. Sixth, the merchant bank processorreceives the response from the payment system, and sends back auniversal receipt to the original point-of-sale device. Seventh, themerchant bank processor then keeps track of the different paymentmethods used for the specific clearing period, and provides settlementreporting, fees and shared fees, risks, auditing information, andexceptions.

FIG. 6 shows how an aggregator, often used by larger corporations, cantake transactions from multiple point of sale devices, multiple paymentsources, and multiple merchant banks, and ultimately supply a largermerchant with a comprehensive payment system optimized for thatparticular merchant's needs.

In some embodiments, it may be useful to make the software compliantwith the Dodd-Frank Wall Street Reform and Consumer Protection Act((Pub.L. 111-203, H.R. 4173). In particular, it may be important tomaintain detailed traceability records of all funds so that financialregulators can, as needed, inspect and verify that all applicableregulations are being complied with.

1. A computerized universal payment method to allow merchants withdiffering risk tolerance, transaction fee tolerance, and payment timetolerance to optimize customer payment transactions that have differentassociated risks, associated transaction fees, and associatedtransaction times, said method comprising; adjusting at least onecustomer payment by a first customer adjustment function of customerpermission, payment method, risk, transaction fee, and payment time,producing at least one universal payment; adjusting said at least oneuniversal payment by a second merchant adjustment function of merchantrisk tolerance, transaction fee tolerance, and payment tolerance,producing a merchant adjusted universal payment; said adjustment beingperformed by at least one computer processor and computer memory; andtransmitting said merchant adjusted universal payment to at least onemerchant or financial representative of said at least one merchant. 2.The method of claim 1, wherein said payment types comprise one or morepayment types selected from the group consisting of Credit Cards,Checks, EBT, Drafts, Promise-to-pay, Script, Debit Card, Gift Card,Payroll Card, ACH, ATM Card, PayPal, Mobile phone, FOB or NFC device,coupons, discounts, cash, ePay or Bill pay, echeck, cross bordertransfers, wire transfer, Giro, and Money Order.
 3. The method of claim1, wherein said at least one customer payment is entered from a point ofsale device.
 4. The method of claim 3, wherein said point-of-sale devicecomprises one or more point-of sale devices selected from the groupconsisting of Standalone, Multi-lane store based, Multi-lane corporatebased, Via PC, Included in Retail System, Included in Restaurant System,Potable standalone, Mobile phone, offline, Internet (PayPal), Mailorder, or Telephone order.
 5. The method of claim 1, wherein when saidat least one customer payment is transmitted over a network connection,the data representing said at least one customer payment also comprisesa data header that at least partially ranks the merchant's preferencesin terms of associated risks, associated transaction fees, andassociated transaction times of payment.
 6. The method of claim 5,wherein the parameters of the desired merchant payment method specifieswhich merchant preference: lowest associated risk, lowest associatedtransaction fees, or lowest associated transaction times of payment ismost important.
 7. The method of claim 5, wherein the merchant furtheruses information about the customer to determine said merchantpreference.
 8. The method of claim 5, wherein the parameters of thedesired merchant payment method specify at least one of a maximumassociated risk, maximum associated transaction fee, or maximumassociated transaction times of payment.
 9. The method of claim 8,wherein the merchant further uses information about the customer todetermine said merchant preference.
 10. The method of claim 1, whereinthe first customer adjustment function of customer permission, paymentmethod, risk, transaction fee, and payment time, and the second merchantadjustment function of merchant risk tolerance, transaction feetolerance, and payment tolerance is done by an electronic marketplacebetween a plurality of merchants and/or other financial entities.
 11. Acomputerized universal payment method to allow merchants with differingrisk tolerance, transaction fee tolerance, and payment time tolerance tooptimize customer payment transactions that have different associatedrisks, associated transaction fees, and associated transaction times,said method comprising; Obtaining formation pertaining to at least onecustomer payment from at least one point-of-sale computerized device,and transmitting said information over an electronic or wireless networkto a universal payment computer; adjusting at least one customer paymentby a first customer adjustment function of customer permission, paymentmethod, risk, transaction fee, and payment time, producing at least oneuniversal payment; adjusting said at least one universal payment by asecond merchant adjustment function of merchant risk tolerance,transaction fee tolerance, and payment tolerance, producing a merchantadjusted universal payment; said adjustment being performed by at leastone computer processor and computer memory and wherein the instructionsto implement said method reside in computer software; and using anelectronic or wireless network to transmit said merchant adjusteduniversal payment to at least one merchant or financial representativeof said at least one merchant.
 12. The method of claim 11, wherein thedata representing said at least one customer payment also comprises adata header that at least partially ranks the merchant's preferences interms of associated risks, associated transaction fees, and associatedtransaction times of payment.
 13. The method of claim 12, wherein theparameters of the desired merchant payment method specifies whichmerchant preference: lowest associated risk, lowest associatedtransaction fees, or lowest associated transaction times of payment ismost important.
 14. The method of claim 12, wherein the merchant furtheruses information about the customer to determine said merchantpreference.
 15. The method of claim 12, wherein the parameters of thedesired merchant payment method specify at least one of a maximumassociated risk, maximum associated transaction fee, or maximumassociated transaction times of payment.
 16. The method of claim 15,wherein the merchant further uses information about the customer todetermine said merchant preference.
 17. The method of claim 11, whereinthe first customer adjustment function of customer permission, paymentmethod, risk, transaction fee, and payment time, and the second merchantadjustment function of merchant risk tolerance, transaction feetolerance, and payment tolerance is done by an electronic marketplacebetween a plurality of merchants and/or other financial entities.
 18. Acomputerized universal payment method to allow merchants with differingrisk tolerance, transaction fee tolerance, and payment time tolerance tooptimize customer payment transactions that have different associatedrisks, associated transaction fees, and associated transaction times,said method comprising; Obtaining formation pertaining to at least onecustomer payment from at least one point-of-sale computerized device,and transmitting said information over an electronic or wireless networkto a universal payment computer; adjusting at least one customer paymentby a first customer adjustment function of customer permission, paymentmethod, risk, transaction fee, and payment time, producing at least oneuniversal payment; adjusting said at least one universal payment by asecond merchant adjustment function of merchant risk tolerance,transaction fee tolerance, and payment tolerance, producing a merchantadjusted universal payment; wherein said data representing said at leastone customer payment also comprises a data header that at leastpartially ranks the merchant's preferences in terms of associated risks,associated transaction fees, and associated transaction times ofpayment; wherein the first customer adjustment function of customerpermission, payment method, risk, transaction fee, and payment time, andthe second merchant adjustment function of merchant risk tolerance,transaction fee tolerance, and payment tolerance is done by anelectronic marketplace between a plurality of merchants and/or otherfinancial entities; said adjustment being performed by at least onecomputer processor and computer memory and wherein the instructions toimplement said method reside in computer software; and using anelectronic or wireless network to transmit said merchant adjusteduniversal payment to at least one merchant or financial representativeof said at least one merchant.
 19. The method of claim 18, wherein theparameters of the desired merchant payment method specifies whichmerchant preference: lowest associated risk, lowest associatedtransaction fees, or lowest associated transaction times of payment ismost important; and wherein the parameters of the desired merchantpayment method also specify at least one of a maximum associated risk,maximum associated transaction fee, or maximum associated transactiontimes of payment.
 20. The method of claim 18, wherein the merchantfurther uses information about the customer to determine said merchantpreference.